-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JanusGraph release candidate 1.0.0-rc1 [cql-tests] [tp-tests] #3350
Conversation
Signed-off-by: Florian Hockmann <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's get this out of door and merge other PRs into 1.0.0-rc2 or?
You mean merge them into |
Why not? |
Why we maybe won't have a rc2? If we don't uncover any problems with rc1 and don't add many breaking changes after rc1 is finished, then we maybe won't see a reason to publish another release candidate and instead directly release 1.0.0. |
Yeah, but have some PRs in the pipeline. So, we could release already a rc1 and get them in before 1.0 so it could be interesting to publish a rc2 before release with freeze phase. |
Yes, sure, I'm also not against doing another release candidate after this. But it could also happen that we get basically no feedback to rc1 and therefore don't see much reason to publish a rc2 after that, especially if there are no big breaking changes happening between rc1 and the final 1.0.0 release. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for leading the release procedure!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this. Thank you @FlorianHockmann !
I have several small notes but otherwise it looks good to me.
- I don't know if we need a separate release notes for
rc1
release indocs/changelog.md
. I.e. if rc1 release will be always available than we probably need separate release notes becauserc1
release and the final release will probably have different upgrade instructions in case we implement more breaking changes into the final release. In case we plan to remove access forrc1
release than we don't need additional release notes for this release. - (not related to this PR) When we publish the release, we need to be clear that some more breaking changes are expected.
- (not related to this PR) We also may need to tell users where to leave their comments regarding the rc release. (should we tell users to add comments to the next thread? https://lists.lfaidata.foundation/g/janusgraph-dev/topic/95312566 )
@@ -166,7 +166,7 @@ nav: | |||
- Changelog: changelog.md | |||
|
|||
extra: | |||
latest_version: 1.0.0 | |||
latest_version: 1.0.0-rc1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if this influences JanusGraph documentation generation or not. I do remember that it has some specific format like x.y.z
but not sure about x.y.z-rc1
format. Probably documentation generation should be fine but I think @farodin91 knows better about the docs generation process, so I will rely on his comments to this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
latest_version is just a string replace.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just searched where it's being used and there are some places in the docs. These fall in 3 categories:
- Name of the distribution build:
janusgraph-{{ latest_version }}.zip
- As the version of the JARs to depend on
- In the URL for Java docs.
The zip archive should include this version and the JARs will also have it so points 1 and 2 are fine. I would also expect the deployment to publish the Java docs although I'm not 100% sure on this. However, there are only 2 links in the docs to the Java docs so it shouldn't be a big problem.
So I'll go ahead now and merge this to proceed with the deployment.
I've basically already wrote my thoughts on this in the PR description (not sure if you saw that):
If we want to add separate upgrade instructions for the release candidates into the changelog, then we either have to copy these into the final instructions again or expect people to read through the upgrade instructions of (possibly) several release candidates and then the final release.
I was thinking about announcing the release candidate on janusgraph-users. We can then inform about the breaking changes there and ask users to also directly submit feedback there (which is then only a reply to the email). |
I checked that couple days ago and then forgot about your points today :)
Yes, that definitely makes sense. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thank you @FlorianHockmann !
Once this PR is merged, I'll continue with the release process and publish the release candidate (or better to say: let our new awesome release process do it). So, if there are issues with the current state on
master
or anything that you think should be included for this release candidate, then please comment here.I've followed the release docs, but did not change the
changelog.md
because I assumed that we don't want to include release candidates there. People can check out the unfinished entry for 1.0.0 there to get an idea of the changes for 1.0.0-rc1. I think that should be enough for a release candidate.Discussion thread: https://lists.lfaidata.foundation/g/janusgraph-dev/topic/95312566